Working Group meeting
Date: 21/03/2023
Participants: Natalie Muric, Wim Kok, Giampaolo Sellitto
Model editor: *Andreea Pasăre
*Note editor: Jana Ahmad
Discussion:
WG discussed the eContract model, mainly the initial contract information requirements:
-
A epo-con: announces contract exists between epo:Contract and epo-con:ContractDocument. Note: Contract document: it is not a contract, it is maybe some additional things such as meta data. What is in the contract is in the contract document.
-
An excel document is created in sharepoint including Contract related concepts and their definitions.
-
epo:bindsBuyer relation created between contract and Buyer.
-
epo:signedByBuyer relation is created between Buyer and contractDocument
WG did a Mapping between Contract model and initial contract information requirements:
-
Issue date, time and identifies should be in the document
-
isSubjectToContractSpesificTerm relation is created between contract and ContractTerm
-
Procurement project type: is contract-nature on ContractTerm
-
Description of Extension and option: epo:ContractTerm has epo:hasOptionsDescription data property. Duration is considered to be about Options.
-
Period start date, Period start time: contractTerm defines the contract period.
-
At-voc:cpvsuppl is removed
-
CPV: At-voc:cpv enumeration is added.
-
CPV supplementary: is not included in ePO
-
Project execution location: epo:ContractTerm defines place of performance which is dct:location
-
Procurement project lot: Contract and lot class is created.
-
Lot identifier:
-
epo:hasTenderReference relation is renamed between contract and tender.
-
epo:hasLotReference relation is renamed between contract and lot.
-
Working Group meeting
Date: 28/02/2023
Participants: Ahmed Abid, Wim Kok, Natalie Muric, Csongor Nyulas, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre, Eugen Costetchi
Note editor: Jana Ahmad
Discussion
GH 370
-
To be closed only after we get confirmation that (and perhaps a link to) an issue asking for the introduction of appropriate code(s) in the at-voc:direct-award-justification vocabulary was opened with DG GROW.
GH 431
-
hasRestatedAwardedValue: This is wrongly modeled and applied in the mappings. It will be updated in the context of modeling eContract. To be discussed in RDF meeting
Procedure and sub-procedure:
-
WG decided to:
-
Separate a procedure from its scope
-
Drop down plan into its phases.
-
-
Notes from WG:
-
Procedure itself is a plan.
-
It is not correct to use process concept to refer to plan/procedure.
-
Nothing is to be executed in procedure, it is just a plan
-
Lot is referring to purpose.
-
-
Plan hierarchy model
-
Lot is procurementSope not a ProcrumentObject
-
-
SelectioCriteria and ExclusionGround are specified for LotQualificationPhase
-
Lot Plan composition model
-
Contain the phases/stages of procurement lifecycle
-
-
Overall plan composition model
-
Note, if we have hundreds of lots and anything is applied to one lot it will be applied to all lots in the same procedure (to be discussed later).
-
We should find a better term than LotPreAwardLifecycle/Workflow.
Working Group meeting
Date: 07/02/2023
Participants: Jana Ahmad, Natalie Muric, Csongor Nyulas
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi
Agenda
-
Standard form mappings - ePO GitHub issues:
-
GH 422 Missing fields F21, IV.2.5, IV.2.9
-
-
Procedure/Sub-procedure
Discussion
GH 442
In the context of concession contracts, the award of procedure actually means procedure. So the “scheduled date for start of award of procedure” is the start of the procedure. We should look into the Directive 2014/24/EU for a better understanding.
Procedure versus sub-procedure
The term procedure has been conflated.
Question: What is a procedure?
Answer: A description of steps taken by someone, a plan.
This plan acts as a general plan for multiple Lots. There are specific plans per each Lot, but the general plan should be fine tuned in order to cover all the Lots.
Within a procurement project we can have a procedure type. Each lot should be executed once or multiple times according to the procedure type.
There are procedural things that are open to all Lots. We can think about it as a procurement procedure.
Some actions/events are reusable within a procedure:
-
Buyer calls for competition [object] (publish Competition Notice)
-
Buyer awards [object] (and publish a Contract Award Notice)
-
Buyer (re-)opens a (mini-)competition [object]
The negotiation action can be part of the competition.
Also, WG discussed re-usable process fragments:
-
Qualification (exclusion grounds and selection criteria)
-
Competition
eAuction and mini competitions are subsets of closed competition.
Some important examples of procedure types are discussed:
-
Restricted procedure:
-
Buyer calls for competition [specific-object] (Competition Notice)
-
Qualification
-
Closed-Competition [specific-object]
-
Buyer awards [specific-object] (Contract Award Notice)
-
-
Restricted procedure with eAuction
-
Restricted procedure with Dynamic Purchasing System
The competition is related to award criteria and the qualification is related to exclusion grounds and selection criteria. All the process fragments should take into consideration the criteria and the appropriate objects.
Plan versus execution
A differentiation between a plan and an execution is discussed.
-
A Plan (~Procedure + Lots) is a detailed proposal for doing or achieving something.
-
Goal: award of a contract
-
-
An *Execution (~ProcedureExecution) *represents the carrying out of a plan, order or course of actions.
-
Achievement: award of a specific contract.
-
We can have procedure executions per Lot (for a Lot there may be one or multiple executions)
-
We can have procedure-executions per Lot. For a lot, there may be one or multiple executions.
There is one execution for the whole procedure.
-
Each lot has one or multiple procedure executions within the “frame” of the “Procedure” execution.
Procurement purpose is split into Lots, and NOT the procedure that is split into lots.
Working Group meeting
Date: 31/01/2023
Participants: Jana Ahmad, Laszlo Ketszeri, Natalie Muric, Csongor Nyulas, Giampaolo Sellito, Marc Christopher
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
The WG discussed: Candidate role: This role exists in ePO version 2.0.2 as epo:CandidateShortList have the following definition: “The tenderers that have been selected in a two stage procedure.
Additional information: the types of procedures that this shortlist applies to are restricted procedures, competitive procedures with negotiation, competitive dialogue procedures and innovation partnerships. The WG approved the previous definition and additional information on (WG 27/07/2018).
epo:EconomicOperatorShortList is a superclass for CandidateShortList. This concept has the following definition: “The Economic Operators that are considered for a given procedure”. The WG approved the previous definition on (WG 22/08/2019).
A new role was added for the next ePO release, epo:Candidate, with the following definition: “The role of an agent that has expressed interest to participate in a competition. The WG approved the previous on (WG 31/01/2023).
The concept is a subclass of epo:OfferingParty as depicted in the diagram below:
Buyer role refinement: The buyer may need to be further refined into AwardingBuyer and AcquiringBuyer, similarly as it is done for the CPB.
GH 421:
Section III.1.* of F21 refers to Selection criteria.
-
Section III.1.4: Objective rules and criteria for participation refers to description in requirement.
-
Codelist to be used in at-voc-applicability.
-
epo:hasreservedProcrument added to ParticipationCondition.
-
epo:hasReservedExcution added to ContractTerm Section III.2. *“contract performance conditions” refers to ContractTerms.
In the eForms they are at the Lot level, but in the standard forms they are at the Procedure level? They are in fact “criteria summaries” for Procedure level
-
Section III.2.1: information about a particular profession refers to ContractTerms
-
information about a particular profession should be mapped to selection criteria summary:
-
In selectionCriteriasummary object two properties are added
-
Eop:hasProfessionRelevantLaw
-
epo:isReservedToParticularProfession
-
BT-79 - III.2.3 - information about staff responsible for the performance of the contract
-
isResponsibleStaffNameIsrequired property is created in ProcrumentCriteriasummary object
-
Two enumerations are added to SelectionCriterien object
-
epo:hasPerformingStaffQualificationInformation is added to epo:ProcurementCriterien
Question: Does SelectioncriteriaSummary inherit from SelectionCriterien?
-
Yes, So then, ProcrumentCriteriaSummary inherits from ProcrumentCriterien.
-
To be checked, when reworking on the Criteria & Criteria Summary: if epo:isReservedToParticularProfession: is the same as the one in the epo:ContractTerm.
Working Group meeting
Date: 24/01/2023
Participants: Jana Ahmad, Laszlo Ketszeri,, Natalie Muric, Csongor Nyulas, Giampaolo Sellito
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi
Discussion
GH 119
-
When we have missing mapping in the technical mapping but the data exists in the standard forms, then we should add the remark in the RDF output as a rdfs:comment.
GH 418
-
The generalisation statement between a role and its type (AcquiringParty, SellerParty or AuxiliaryParty) should not be present in the technical mapping.
-
This ticket and https://github.com/OP-TED/ted-rdf-mapping/issues/289 were closed, with the same resolution.
GH 419
The property epo:hasLotAwardLimit has been deleted.
epo:hasMaximumNumberOfLotsToBeAwarded is kept.
GH 420
-
In the standard form, we have just generalised information (generalisation criterion) at the procedure level.
-
And the procurement criteria is specified for the lot level .
-
In the standard form, procedure specifies criteria summary (so we can have summary criterion at the procedure level .).
-
We should differentiate between criteria and criteria summary
-
Create participation criterion class in a lot level (so we have 4 criteria now).
-
Participation is at the submission level.
-
Participation conditions should be even before submission
-
Two approaches for Criteria modelling (concept and instance diagrams) have been presented and are depicted below.
Example 1
Concept diagram:
Instance diagram:
Example 2
-
Submission terms:
-
Submission terms: rules for submission
-
Submission terms has participation condition
-
Participation conditions had reserved procurement.
-
-
Create criteria summary diagram to differentiate between procurement criteria and procurement criteria summary:
-
If the procurement criteria goes to the procurement object, Ground exclusion is the same for all lots.
-
Suggestion to add relation between Selection Criteria and Selection Criteria Summary (aggregation relation).
-
-
Decided to model the following:
Working Group meeting
Date: 17/01/2023
Participants: Jana Ahmad, Natalie Muric, Pietro Palermo, Thomas Pettersson, Giampaolo Sellito, Emidio Stani, Ivan Willer
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi
Discussion
-
Org ontology link: https://www.w3.org/TR/vocab-org/
Core Vocabularies observations
-
epo:hasOrganisationUnit should be an attribute on the OrganisationalUnit concept from org ontology.
-
If we follow org ontology we need to add a new class where to put only an attribute for the name.
-
The reason why we conflated these two is the case when only a particular unit is the Buyer.
-
Recommendation to not separate these two concepts (Organisation and Organisation Unit) and only rename the attribute to epo:hasOrganisationUnitName
-
Why? Because the Agent that takes a role (e.g. Buyer) can be a Unit or an organisation, but we decided to set the description at the “organisation level”.
-
-
epo:hasLegalFormType - from SEMIC perspective we asked the OP to create the Core Vocabulary for the classification of the legal forms from GLEIF:
-
This will be published in the future.
-
Switch to using a code list for legal type classifications.
-
cv:LegalEntity versus epo:Business
Definition for cv:LegalEntity:
A self-empoyed person, company, or organization that has legal rights and obligations.
Definition for epo:Business:
A private law company registered in a national registry.
-
epo:Business should be a subclass of cv:LegalEntity in Core Business Vocabulary.
-
In order to align with Core Voc, it means we need to add cv:LegalEntity and org:FormalOrganization between org:Organization and epo:Business.
-
But a Business has to be a FormalOrganization.
-
In CPOV, a PublicOrganisation is not org:FormalOrganisation, but it is directly under org:Organisation.
-
Depending on the country, a cpov:PublicOrganisation may have a legal entity, so it may be a formal organisation.
-
Hierarchy
-
Org:Organisation
-
cv:PublicOrganisation
-
org:FormalOrganisation
-
legal:LegalEntity (self-employed person, company, or organisation with certain rights)
-
Action: Replace epo:Business by cv:LegalEntity
-
-
-
epo:OrganisationGroup
-
-
-
We need to have a discussion on whether the legal form type is at the legal entity level or at the organisation level.
-
What if we have the case when a tenderer is a public organisation?
-
-
This relationship is used at the Organisation level because foaf:Agent includes also a person or a system.
-
Decided to remove the relation from epo:OfferingParty to epo:Business as depicted in the diagram above.
-
Checking on whether we had a formal organisation in older versions of ePO 2.0.1 and it was not.
-
But in 12th May 2020 WGM minutes it appears to have been created an epo:FormalOrganization concept: https://docs.ted.europa.eu/epo-wgm/notes/2020-05-12-wgm.html
Concession contract
-
In CPSV-AP the cv:ServiceConcessionContract was added as a subclass of epo:ConcessionContract:
-
For CPSV-AP we need a relationship between epo:Contract to epo:ContractSpecificTerm (epo:hasContractTerm) in order to be able to get to the at-voc:contract-nature:
-
Contract includes specific terms
-
Contract cannot have epo:ContractSpecificterms
-
Contract “includes Lot”, is not right, needs more discussion on this.
Order
-
Look into the syntax binding, where we will see all the “elements” that we need to see in the order.
-
For example, Contract ID, is missing, or what is in the Buyer? It is hard to see all the elements from the ePOcore or eCatalogue, or eFulfillment.
-
Request: can we have a plain table with all properties for a class (including inherited attributes).
-
Technical Question:
-
Given a UML model, can we generate an “application profile” in a tabular representation (see SKOS-AP-EU ), for each class considering also inheritance.
-
Can we also automatically generate a “Path” to get that property?
-
-
-
It was found that a epo:ProcurementElement does not have an identifier, so the relation between epo:ProcurementObject and epo:Identifier was moved from epo:ProcurementElement to epo:Identifier as depicted in the diagram below:
-
Proposal to work on a table that contains all the properties for all the concepts in the Order phase on the 26th Jan.
Working Group meeting
Date: 10/01/2023
Participants: Jana Ahmad, Vladimir Alexiev, Emiel Dhondt, Juris Kalejs, Wim Kok, Natalie Muric, Giampaolo Sellito, Emidio Stani
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
Core Vocabularies observations
cpv:Person
-
data type is Changed from rdfs:Literal to rdf:langString in the following properties :
-
foaf:name
-
foaf:familyname
-
foaf:givenName
-
person:patronymicName
-
dct:alternative
-
-
cv:deathDate Removed from cpv:Person.
cpov:ContactPoint
-
epo:hasInternetAddress is similar to contactPage with foaf:Document as range.
-
Proposal by Core Vocabularies to change the range to anyURI so this contactPage can be adapted by ePO as well.
-
Based on the standard forms, epo:hasInternetAddress is probably the URL of the Organization and not of the ContactPoint.
-
Proposal to add epo:hasHomePage (xsd:anyURI, [0..*]) as an attribute on org:Organization concept with the following definition: “The main web page.”
cv:Channel
-
epo:hasDescription is similar to http://purl.org/dc/terms/description
-
If we change the datatype to LangString, we need to change them all.
-
rdfs:Literal allows integers, booleans and LangString, etc.
-
We need to revise data types and make them more specific.
-
Better to use rdf:PlainLiteral, see GitHub ticket: https://github.com/OP-TED/ePO/issues/405
-
Instead of epo:hasDescription switch dct:description.
-
epo:hasURL is mandatory property, but it should not be, because sometimes we might need to use epo:isAdhocChannel.
-
In standard forms AdhocChannel is not a boolean, but in eForms it is.
-
The AdhocChannel should not be CommunicationMean.
-
An Organization hasCommunicationMeans either a Channel or a DeliveryGateway.
epo:AgentInRole
-
The attribute epo:hasTitle was changed to dct:title and the definition modified accordingly.
epo:Identifier
-
WG discussed whether to use dct:identifier instead of epo:hasID.
-
But dct:identifier has a range of rdfs:Literal and can not be used.
-
We need to decide on whether to change to adms:identifier (old github issue: https://github.com/OP-TED/ePO/issues/258)
-
If we need more properties for ePO we should add a ticket to adms.
euBusinessGraph Semantic Data Model
-
https://docs.google.com/document/d/1dhMOTlIOC6dOK_jksJRX0CB-GIRoiYY6fWtCnZArUhU/edit#
-
Presenting the reg org vocabulary: https://www.w3.org/TR/vocab-regorg/
locn:Address
-
All attributes data types are changed from rdfs:Literal to rdf:langString, except locn:postCode and locn:locatorDesignator.
CCCEV
On cccev:Requirement:
-
cccev:description changed to dct:description (rdf:PlainLiteral).
-
cccev:identifier changed to dct:identifier.
-
We need to use an identifier for requirements.
-
To stay consistent to how identification is realised in ePO, we switched to using adms:identifier instead of dct:identifier as per CCCEV requirement.
-
Instead of cccev:name we will use skos:prefLabel (rdf:PlainLiteral).
-
There should be only one description and we added as additional information that we can have multiple languages for the same description. (see https://www.w3.org/TR/skos-reference/#L1567)
-
On cccev:type changed to dct:type
-
On cccev:InformationConcept, hasDescription and hasTitle are changed to dct:description and skos:prefLabel.
WG disscussed the Channel
-
In standard form we have the following section for communication:
-
We want to use the AdhocChannel as a URL and not a boolean.
-
We might need to remove epo:hasAdditionalInformation and epo:hasName from cv:Channel.
-
In CPVS-AP, cpsv:PublicService has a cv:Channel.
-
We need to do a comparison to version ePO 2.0.1.
-
Adding epo:hasToolsAccessURL (xsd:anyURI, [0..1]) attribute to epo:AccessTerm concept with the following definition: “Web page where the tools and devices for electronic communication that are not generally available can be downloaded free of charge.”
-
This needs to be further discussed.
-
cv:Channel was moved from org:Organization level to epo:AgentInRole level.
-
In PEPPOL, an endpoint is an identifier.
-
The cv:Channel class was deleted.
-
We need to further discuss the difference between epo:Business and cv:LegalEntity.